Systems and methods for optimizing nested loop instructions in pipeline processing stages within a machine perception and dense algorithm integrated circuit

ABSTRACT

In one embodiment, a method for improving a performance of an integrated circuit includes implementing one or more computing devices executing a compiler program that: (i) evaluates a target instruction set intended for execution by an integrated circuit; (ii) identifies one or more nested loop instructions within the target instruction set based on the evaluation; (iii) evaluates whether a most inner loop body within the one or more nested loop instructions comprises a candidate inner loop body that requires a loop optimization that mitigates an operational penalty to the integrated circuit based on one or more executional properties of the most inner loop instruction; and (iv) implements the loop optimization that modifies the target instruction set to include loop optimization instructions to control, at runtime, an execution and a termination of the most inner loop body thereby mitigating the operational penalty to the integrated circuit.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.17/127,213, filed 18 Dec. 2020, which claims the benefit of U.S.Provisional Application No. 62/957,688, filed 6 Jan. 2020, and of theU.S. Provisional Application No. 63/050,971, filed 13 Jul. 2020, whichare incorporated herein in their entireties by this reference.

TECHNICAL FIELD

The one or more inventions described herein relate generally to theintegrated circuitry field, and more specifically to a new and usefulperception and dense algorithm processing integrated circuitryarchitecture in the integrated circuitry field.

BACKGROUND

Modern applications of artificial intelligence and generally, machinelearning appear to be driving innovations in robotics and specifically,in technologies involving autonomous robotics and autonomous vehicles.Also, the developments in machine perception technology have enabled theabilities of many of the implementations in the autonomous robotics' andautonomous vehicles' spaces to perceive vision, perceive hearing, andperceive touch among many other capabilities that allow machines tocomprehend their environments.

The underlying perception technologies applied to these autonomousimplementations include a number of advanced and capable sensors thatoften allow for a rich capture of environments surrounding theautonomous robots and/or autonomous vehicles. However, while many ofthese advanced and capable sensors may enable a robust capture of thephysical environments of many autonomous implementations, the underlyingprocessing circuitry that may function to process the various sensorsignal data from the sensors often lack in corresponding robustprocessing capabilities sufficient to allow for high performance andreal-time computing of the sensor signal data.

The underlying processing circuitry often include general purposeintegrated circuits including central processing units (CPUs) andgraphic processing units (GPU). In many applications, GPUs areimplemented rather than CPUs because GPUs are capable of executing bulkyor large amounts of computations relative to CPUs. However, thearchitectures of most GPUs are not optimized for handling many of thecomplex machine learning algorithms (e.g., neural network algorithms,etc.) used in machine perception technology. For instance, theautonomous vehicle space includes multiple perception processing needsthat extend beyond merely recognizing vehicles and persons. Autonomousvehicles have been implemented with advanced sensor suites that providea fusion of sensor data that enable route or path planning forautonomous vehicles. But, modern GPUs are not constructed for handlingthese additional high computation tasks.

At best, to enable a GPU or similar processing circuitry to handleadditional sensor processing needs including path planning, sensorfusion, and the like, additional and/or disparate circuitry may beassembled to a traditional GPU. This fragmented and piecemeal approachto handling the additional perception processing needs of robotics andautonomous machines results in a number of inefficiencies in performingcomputations including inefficiencies in sensor signal processing.

Accordingly, there is a need in the integrated circuitry field for anadvanced integrated circuit and processing techniques that are capableof high performance and real-time processing and computing of routineand advanced sensor signals for enabling perception of robotics or anytype or kind of perceptual machine.

The inventors of the inventions described in the present applicationhave designed an integrated circuit architecture and one or moreprocessing techniques that allow for enhanced sensor data processingcapabilities and have further discovered related methods forimplementing the integrated circuit architecture for several purposesincluding for enabling perception of robotics and various machines.

SUMMARY OF THE INVENTION(S)

In one embodiment, a method for improving a performance of an integratedcircuit includes implementing one or more computing devices executing acompiler program that: (i) evaluates a target instruction set intendedfor execution by an integrated circuit; (ii) identifies one or morenested loop bodies within the target instruction set based on theevaluation; (iii) evaluates whether a most inner loop body within theone or more nested loop bodies comprises a candidate inner loop bodythat requires a loop optimization that mitigates an operational penaltyto the integrated circuit based on one or more executional properties ofthe most inner loop body; and (iv) implements the loop optimization thatmodifies the target instruction set to include loop optimizationinstructions to control, at runtime, an execution and a termination ofthe most inner loop body thereby mitigating the operational penalty tothe integrated circuit.

In one embodiment, each iteration of the most inner loop body isexecuted by an array processing core of an integrated circuit array ofthe integrated circuit that includes a plurality of array processingcores; and the loop optimization causes a distinct processing circuitexternal to the integrated circuit array to (a) control a start of theexecution of each iteration by the array processing core and (b) controla termination of an execution of the most inner loop body by the arrayprocessing core.

In one embodiment, if the most inner loop body within the loop body ofthe nested loop bodies is associated with an instruction for backwardsbranching, automatically setting the most inner loop body as thecandidate inner loop for the loop optimization.

In one embodiment, the evaluation further includes: (i) identifying acode size of the candidate inner loop, (ii) identifying whether the codesize of the candidate inner loop satisfies or does not exceed aninstruction size threshold, wherein the instruction size thresholdrelates to a maximum possible code size of a potential candidate forloop optimization, and wherein automatically setting the most inner loopbody as the candidate inner loop for the loop optimization when the codesize of the candidate inner loop satisfies or does not exceed theinstruction size threshold.

In one embodiment, the evaluation further includes: (i) inspecting astructure of the candidate inner loop; (ii) identifying whether loopbounds of the candidate inner loop is discoverable based on theinspection; and (iii) if the loop bounds of the candidate inner loop arediscoverable, deriving a starting condition and a deriving terminatingcondition of the candidate inner loop, wherein a combination of thestarting condition and the terminating condition define the loop boundsof the candidate inner loop.

In one embodiment, the loop optimization instructions comprise animplicit branch instruction that controls a looping operation of thecandidate inner loop.

In one embodiment, the implicit branch instruction comprises amulti-part branch instruction that is instructionally tethered to a loopbody of the candidate inner loop for controlling a looping backoperation of the candidate inner loop without a need for executingexplicit backward branching instructions within the loop body of thecandidate inner loop.

In one embodiment, the implicit branch instruction comprises amulti-position branch instruction having (a) a first part comprising afirst instruction that is positioned ahead of the loop body of thecandidate inner loop and (b) a second part comprising one or more bitsof instruction that are positioned within the loop body of the candidateinner loop.

In one embodiment, a first part of the multi-part branch instructioncomprises an antecedent instruction that is codified at a position aheadof the loop body of the candidate inner loop.

In one embodiment, the antecedent instruction comprises loop bounds ofthe candidate inner loop, wherein the loop bounds include a startingcondition and a terminating condition of the candidate inner loop.

In one embodiment, the antecedent instructions includes a code locationtarget that identifies a starting instruction of the loop body of thecandidate inner loop.

In one embodiment, a second part of the multi-part branch instructioncomprises a suffixation bit that includes a single bit of instructionappended to a terminal instruction of the loop body of the candidateinner loop or that is arranged in a position within the loop body of thecandidate inner loop.

In one embodiment, the single bit of instruction identifies a terminalinstruction of the loop body of the candidate inner loop that, whenexecuted, causes a reversion to a code location target of the antecedentinstructions that identifies a starting instruction of the loop body ofthe candidate inner loop.

In one embodiment, an execution of the single bit of instruction causesan increment or a decrement to a dedicated loop counter for thecandidate inner loop.

In one embodiment, executing, at runtime, the antecedent instructionsincludes storing the loop bounds in a memory distinct from a memorystoring the loop body of the candidate inner loop, clearing andinitializing a dedicated loop counter for the candidate inner loop.

In one embodiment, a system for improving a performance of an integratedcircuit includes one or more computing devices executing a compilerprogram that: (i) evaluates a target instruction set intended forexecution by an integrated circuit; (ii) identifies one or more nestedloop instructions within the target instruction set based on theevaluation; (iii) evaluates whether a most inner loop body within theone or more nested loop instructions comprises a candidate inner loopbody that requires a loop optimization that mitigates an operationalpenalty to the integrated circuit based on one or more executionalproperties of the most inner loop instruction; and (iv) implements theloop optimization that modifies the target instruction set to includeloop optimization instructions to control, at runtime, an execution anda termination of the most inner loop body thereby mitigating theoperational penalty to the integrated circuit.

In one embodiment, the loop optimization instructions comprise amulti-part implicit branch instruction that is instructionally tetheredto a loop body of the candidate inner loop for controlling a loopingback operation of the candidate inner loop; the multi-part implicitbranch including: (a) a first part that is codified at a position aheadof the loop body of the candidate inner loop and that causes a storingof loop bounds of the candidate inner loop, and (b) a second part thatincludes a single bit of instruction arranged within the loop body ofthe candidate inner loop that identifies a terminal instruction of theloop body of the candidate inner loop and that, when executed, causes areversion to a storage location of the loop bounds and/or a codelocation target of the antecedent instructions that identifies astarting instruction of the loop body of the candidate inner loop.

In one embodiment, a method for improving an operational performance ofan integrated circuit includes controlling an execution of a loopingoperation of a target nested loop within a subject set of instructions,wherein the controlling includes: (i) executing, by a distinctprocessing circuit, a first part of an implicit branch instruction forthe target nested loop, wherein the executing the first part includes:(i-a) storing loop bounds of the target nested loop in a memory distinctfrom a memory storing the loop body of the target nested loop, (i-b)clearing and initializing a dedicated loop counter for the target nestedloop, (i-c) storing a code location target of a starting instruction ofthe loop body of the candidate inner loop, wherein the dedicated loopcounter for the target nested loop is incremented or decrementedaccording to each executed iteration of the target nested loop; (ii)executing, by the distinct processing circuit, a second part of theimplicit branch instruction, wherein the second part includes a singlebit instruction arranged within the loop body of the candidate innerloop, wherein the executing the second part includes: (ii-a) causes areversion to a storage location of the loop bounds, and (ii-b) anincrement or a decrement of the dedicated loop counter for the targetnested loop; wherein controlling the execution includes: continuing theexecution or terminating the execution of the loop body of the targetnest loop by an array processing circuit of an integrated circuit arraybased on whether a value of the dedicated loop counter satisfies aterminating condition defined in the loop bounds.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a schematic of a system 100 in accordance with one ormore embodiments of the present application;

FIG. 2 illustrates a method 200 for implementing a predicate stack inaccordance with one or more embodiments of the present application;

FIG. 3 illustrates a schematic that examples loop optimization atcompile time in accordance with one or more embodiments of the presentapplication; and

FIGS. 4A-4B illustrate schematics that example an execution of a loopoptimized with implicit branch instructions in accordance with one ormore embodiments of the present application.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description of preferred embodiments of the presentapplication are not intended to limit the inventions to these preferredembodiments, but rather to enable any person skilled in the art of tomake and use these inventions.

I. Overview

In an integrated circuit configured with pipeline processing stages, abackwards branching instruction may cause stalls in the execution of oneor more instruction sets thereby increasing a number clock cyclesrequired for processing the instruction set and reducing a performanceof the integrated circuit. Backwards branching instructions maytypically be found in loop instructions and the like in which anexecution of a new iteration of the loop may require that the integratedcircuit jump from a terminal instruction of a loop body of the loop backto a branch for executing a new iteration of the loop instructions.Additionally, for certain instruction types such as tight nested loops,stalls may be extremely expensive when the nest loop is really small(e.g., a small number of instructions below a code size threshold or thelike). To avoid the stalls, in some integrated circuits, branchpredictors may be implemented that make predictions on whether a branchwill or will not be taken or executed. In pipeline processing stages, abranch predictor may reduce stalls, however, branch predictors are oftencomplex and expensive, in terms of computational resources (e.g., power,chip area, etc.), to deploy.

One alternative for reducing a stall penalty resulting from backwardsbranching includes unrolling the code or instruction set, which mayreduce a stall penalty by half while simultaneously enlarging the codesize. However, in many embedded systems, available memory for storinginstructions or code is limited and thus, unrolling the code set mayreduce a stall penalty to improve a performance of an integratedcircuit, but unrolling also grows the size of the code by double witheach unrolling. In such cases, an embedded system may not havesufficient memory to store the increased code size and/or havesufficient available memory to properly executed large code, at runtime.

One or more embodiments of the present application, however, providesystems and techniques for optimizing instruction sets that includebackwards branching instructions that may typically produce a stall inexecution. In one preferred embodiment of the present application, aninstruction set may be optimized to include an implicit branchinginstruction that abstracts the processing task from a processing circuitexecuting a nested loop or the like and allows a distinct processingentity (e.g., an IMD (instruction memory dispatcher)) other than anarray core of the integrated circuit array to handle the start ofiterations of the nested loop and the termination of the nested loop byimplementing a setup instruction with a branch target having startingand terminating conditions together with a loopback bit or a reservedbit reverts the distinct processing entity to the branch target foreither restarting the loop or terminating the loop, as described in moredetail below.

It shall also be recognized that the one or more embodiments of thepresent application may be implemented in any suitable processingenvironment including, but not limited to, within one or more IMDsand/or any suitable processing circuit.

The mesh architecture defined by the plurality of processing elements inthe array core preferably enable in-memory computing and data movement,as described in U.S. Pat. No. 10,365,860, U.S. patent application Ser.No. 16/292,537, U.S. Provisional Application Nos. 62/649,551 and62/649,551, which are all incorporated herein in their entireties bythis reference and further, enable a core-level predication.

II. A System Architecture of a Dense Algorithm and/or PerceptionProcessing Circuit (Unit)

As shown in FIG. 1, the integrated circuit 100 (dense algorithm and/orperception processing unit) for performing perception processingincludes a plurality of array cores 110, a plurality of border cores120, a dispatcher (main controller) 130, a first plurality of peripherycontrollers 140, a second plurality of periphery controllers 150, andmain memory 160. The integrated circuit 100 may additionally include afirst periphery load store 145, a second periphery load store 155, afirst periphery memory 147, a second periphery memory 157, a firstplurality of dual FIFOs 149, and a second plurality of dual FIFOs 159,as described in U.S. Pat. Nos. 10,365,860, 10,691,464, and U.S. patentapplication Ser. No. 16/292,537, which are all incorporated herein intheir entireties by this reference.

The integrated circuit 100 preferably functions to enable real-time andhigh computing efficiency of perception data and/or sensor data. Ageneral configuration of the integrated circuit 100 includes a pluralityof array core 110 defining central signal and data processing nodes eachhaving large register files that may eliminate or significantly reduceclock cycles needed by an array core 110 for pulling and pushing datafor processing from memory. The instructions (i.e.,computation/execution and data movement instructions) generatingcapabilities of the integrated circuit 100 (e.g., via the dispatcher 130and/or a compiler module 175) functions to enable a continuity and flowof data throughout the integrated circuit 100 and namely, within theplurality of array cores 110 and border cores 120.

An array core 110 preferably functions as a data or signal processingnode (e.g., a small microprocessor) or processing circuit andpreferably, includes a register file 112 having a large data storagecapacity (e.g., 1024 kb, etc.) and an arithmetic logic unit (ALU) 118 orany suitable digital electronic circuit that performs arithmetic andbitwise operations on integer binary numbers. In a preferred embodiment,the register file 112 of an array core 110 may be the only memoryelement that the processing circuits of an array core 110 may havedirect access to. An array core 110 may have indirect access to memoryoutside of the array core and/or the integrated circuit array 105 (i.e.,core mesh) defined by the plurality of border cores 120 and theplurality of array cores 110.

The register file 112 of an array core 110 may be any suitable memoryelement or device, but preferably comprises one or more staticrandom-access memories (SRAMs). The register file 112 may include alarge number of registers, such as 1024 registers, that enables thestorage of a sufficiently large data set for processing by the arraycore 110. Accordingly, a technical benefit achieved by an arrangement ofthe large register file 112 within each array core 110 is that the largeregister file 112 reduces a need by an array core 110 to fetch and loaddata into its register file 112 for processing. As a result, a number ofclock cycles required by the array core 112 to push data into and pulldata out of memory is significantly reduced or eliminated altogether.That is, the large register file 112 increases the efficiencies ofcomputations performed by an array core 110 because most, if not all, ofthe data that the array core 110 is scheduled to process is locatedimmediately next to the processing circuitry (e.g., one or more MACs,ALU, etc.) of the array core 110. For instance, when implementing imageprocessing by the integrated circuit 100 or related system using aneural network algorithm(s) or application(s) (e.g., convolutionalneural network algorithms or the like), the large register file 112 ofan array core may function to enable a storage of all the image datarequired for processing an entire image. Accordingly, most or if not,all layer data of a neural network implementation (or similarcompute-intensive application) may be stored locally in the largeregister file 112 of an array core 110 with the exception of weights orcoefficients of the neural network algorithm(s), in some embodiments.Accordingly, this allows for optimal utilization of the computing and/orprocessing elements (e.g., the one or more MACs and ALU) of an arraycore 110 by enabling an array core 110 to constantly churn data of theregister file 112 and further, limiting the fetching and loading of datafrom an off-array core data source (e.g., main memory, periphery memory,etc.).

By comparison, to traverse a register file in a traditional systemimplemented by a GPU or the like, it is typically required that memoryaddresses be issued for fetching data from memory. However, in apreferred embodiment that implements the large register file 112, the(raw) input data within the register file 112 may be automaticallyincremented from the register file 112 and data from neighboring core(s)(e.g., array cores and/or border cores) are continuously sourced to theregister file 112 to enable a continuous flow to the computing elementsof the array core 110 without an express need to make a request (orissuing memory addresses) by the array core 110.

While in some embodiments of the present application, a predetermineddata flow scheduled may mitigate or altogether, eliminate requests fordata by components within the integrated circuit array 105, in a variantof these embodiments traditional random memory access may be achieved bycomponents of the integrated circuit array 105. That is, if an arraycore 110 or a border core 120 recognizes a need for a random piece ofdata for processing, the array core 110 and/or the border 120 may make aspecific request for data from any of the memory elements within thememory hierarchy of the integrated circuit 100.

An array core 110 may, additionally or alternatively, include aplurality of multiplier (multiply) accumulators (MACs) 114 or anysuitable logic devices or digital circuits that may be capable ofperforming multiply and summation functions. In a preferred embodiment,each array core 110 includes four (4) MACs and each MAC 114 may bearranged at or near a specific side of a rectangular shaped array core110. While, in a preferred embodiment each of the plurality of MACs 114of an array core 110 may be arranged near or at the respective sides ofthe array core 110, it shall be known that the plurality of MACs 114 maybe arranged within (or possibly augmented to a periphery of an arraycore) the array core 110 in any suitable arrangement, pattern, position,and the like including at the respective corners of an array core 110.In a preferred embodiment, the arrangement of the plurality of MACs 114along the sides of an array core 110 enables efficient inflow or captureof input data received from one or more of the direct neighboring cores(i.e., an adjacent neighboring core) and the computation thereof by thearray core 110 of the integrated circuit 100.

Accordingly, each of the plurality of MACs 114 positioned within anarray core 110 may function to have direct communication capabilitieswith neighboring cores (e.g., array cores, border cores, etc.) withinthe integrated circuit boo. The plurality of MACs 114 may additionallyfunction to execute computations using data (e.g., operands) sourcedfrom the large register file 112 of an array core 110. However, theplurality of MACs 114 preferably function to source data for executingcomputations from one or more of their respective neighboring core(s)and/or a weights or coefficients (constants) bus 116 that functions totransfer coefficient or weight inputs of one or more algorithms(including machine learning algorithms) from one or more memory elements(e.g., main memory 160 or the like) or one or more input sources.

The weights bus 116 may be operably placed in electrical communicationwith at least one or more of periphery controllers 140, 150 at a firstinput terminal and additionally, operably connected with one or more ofthe plurality of array core 110. In this way, the weight bus 116 mayfunction to collect weights and coefficients data input from the one ormore periphery controllers 140, 150 and transmit the weights andcoefficients data input directly to one or more of the plurality ofarray cores no. Accordingly, in some embodiments, multiple array cores110 may be fed weights and/or coefficients data input via the weightsbus 116 in parallel to thereby improve the speed of computation of thearray cores 110.

Each array core 110 preferably functions to bi-directionally communicatewith its direct neighbors. That is, in some embodiments, a respectivearray core 110 may be configured as a processing node having arectangular shape and arranged such that each side of the processingnode may be capable of interacting with another node (e.g., anotherprocessing node, a data storage/movement node, etc.) that is positionednext to one of the four sides or each of the faces of the array core110. The ability of an array core no to bi-directionally communicatewith a neighboring core along each of its sides enables the array core110 to pull in data from any of its neighbors as well as push (processedor raw) data to any of its neighbors. This enables a mesh communicationarchitecture that allows for efficient movement of data throughout thecollection of array and border cores 110, 120 of the integrated circuit100.

Each of the plurality of border cores 120 preferably includes a registerfile 122. The register file 122 may be configured similar to theregister file 112 of an array core 110 in that the register file 122 mayfunction to store large datasets. Preferably, each border core 120includes a simplified architecture when compared to an array core 110.Accordingly, a border core 120 in some embodiments may not includeexecution capabilities and therefore, may not includemultiplier-accumulators and/or an arithmetic logic unit as provided inmany of the array cores 110.

In a traditional integrated circuit (e.g., a GPU or the like), wheninput image data (or any other suitable sensor data) received forprocessing compute-intensive application (e.g., neural networkalgorithm) within such a circuit, it may be necessary to issue paddingrequests to areas within the circuit which do not include image values(e.g., pixel values) based on the input image data. That is, duringimage processing or the like, the traditional integrated circuit mayfunction to perform image processing from a memory element that does notcontain any image data value. In such instances, the traditionalintegrated circuit may function to request that a padding value, such aszero, be added to the memory element to avoid subsequent imageprocessing efforts at the memory element without an image data value. Aconsequence of this typical image data processing by the traditionalintegrated circuit results in a number of clock cycles spent identifyingthe blank memory element and adding a computable value to the memoryelement for image processing or the like by the traditional integratedcircuit.

In a preferred implementation of the integrated circuit 100, one or moreof the plurality of border cores 120 may function to automatically setto a default value when no input data (e.g., input sensor data) isreceived. For instance, input image data from a sensor (or anothercircuit layer) may have a total image data size that does not occupy allborder core cells of the integrated circuit array 105. In such instance,upon receipt of the input image data, the one or more border cores 120(i.e., border core cells) without input image data may be automaticallyset to a default value, such as zero or a non-zero constant value.

In some embodiments, the predetermined input data flow schedulegenerated by the dispatcher and sent to one or more of the plurality ofborder cores may include instructions to set to a default or apredetermined constant value. Additionally, or alternatively, the one ormore border cores 120 may be automatically set to a default or apredetermined value when it is detected that no input sensor data or thelike is received with a predetermined input data flow to the integratedcircuit array 105. Additionally, or alternatively, in one variation, theone or more border cores 120 may be automatically set to reflect valuesof one or more other border cores having input sensor data when it isdetected that no input sensor data or the like is received with apredetermined input data flow to the integrated circuit array 105.

Accordingly, a technical benefit achieved according to theimplementation of one or more of the plurality of border cores 120 asautomatic padding elements, may include increasing efficiencies incomputation by one or more of the plurality of array cores 110 byminimizing work requests to regions of interest (or surrounding areas)of input sensor data where automatic padding values have been set.Thereby, reducing clock cycles used by the plurality of array core 110in performing computations on an input dataset.

In a preferred implementation of the integrated circuit 100, theprogression of data into the plurality of array cores 110 and theplurality of border cores 120 for processing is preferably based on apredetermined data flow schedule generated at the dispatcher 130. Thepredetermined data flow schedule enables input data from one or moresources (e.g., sensors, other NN layers, an upstream device, etc.) to beloaded into the border cores 120 and array cores 110 without requiringan explicit request for the input data from the border cores 120 and/orarray cores 110. That is, the predetermined data flow schedule enablesan automatic flow of raw data from memory elements (e.g., main memory160) of the integrated circuit 100 to the plurality of border cores 120and the plurality of array cores 110 having capacity to accept data forprocessing. For instance, in the case that an array core 110 functionsto process a first subset of data of a data load stored in its registerfile 112, once the results of the processing of the first subset of datais completed and sent out from the array core 110, the predetermineddata flow schedule may function to enable an automatic flow of raw datainto the array core 110 that adds to the data load at the register file112 and replaces the first subset of data that was previously processedby the array core 110. Accordingly, in such instance, no explicitrequest for additional raw data for processing is required from thearray core 110. Rather, the integrated circuit 100 implementing thedispatcher 130 may function to recognize that once the array core 110has processed some amount of data sourced from its register file 112 (orelsewhere) that the array core 110 may have additional capacity toaccept additional data for processing.

In a preferred embodiment, the integrated circuit 100 may be in operablecommunication with an instructions generator 170 that functions togenerate computation, execution, and data movement instructions, asshown by way of example in FIG. 3A. The instructions generator 170 maybe arranged off-chip relative to the components and circuitry of theintegrated 100. However, in alternative embodiments, the instructionsgenerator 170 may be cooperatively integrated within the integratedcircuit 100 as a distinct or integrated component of the dispatcher 130.

Preferably, the instructions generator 170 may be implemented using oneor more general purpose computers (e.g., a Mac computer, Linux computer,or any suitable hardware computer) or general purpose computerprocessing (GPCP) units 171 that function to operate a compiler module175 that is specifically configured to generate multiple and/ordisparate types of instructions. The compiler module 175 may beimplemented using any suitable compiler software (e.g., a GNU CompilerCollection (GCC), a Clang compiler, and/or any suitable open sourcecompiler or other compiler). The compiler module 175 may function togenerate at least computation instructions and execution instructions aswell as data movement instructions. In a preferred embodiment, atcompile time, the compiler module 175 may be executed by the one or moreGPCP units 171 to generate the two or more sets of instructionscomputation/execution instructions and data movement instructionssequentially or in parallel. In some embodiments, the compiler module175 may function to synthesize multiple sets of disparate instructionsinto a single composition instruction set that may be loaded into memory(e.g., instructions buffer, an external DDR, SPI flash memory, or thelike) from which the dispatcher may fetch the single compositioninstruction set from and execute.

In a first variation, however, once the compiler module 175 generatesthe multiple disparate sets of instructions, such as computationinstructions and data movement instructions, the instructions generator170 may function to load the instructions sets into a memory (e.g.,memory 160 or off-chip memory associated with the generator 170). Insuch embodiments, the dispatcher 130 may function to fetch the multiplesets of disparate instructions generated by the instructions generator170 from memory and synthesize the multiple sets of disparateinstructions into a single composition instruction set that thedispatcher may execute and/or load within the integrated circuit 100.

In a second variation, the dispatcher 130 may be configured withcompiling functionality to generate the single composition instructionset. In such variation, the dispatcher 130 may include processingcircuitry (e.g., microprocessor or the like) that function to createinstructions that include scheduled computations or executions to beperformed by various circuits and/or components (e.g., array corecomputations) of the integrated circuit 100 and further, createinstructions that enable a control a flow of input data through theintegrated circuit 100. In some embodiments, the dispatcher 130 mayfunction to execute part of the instructions and load another part ofthe instructions into the integrated circuit array 105. In general, thedispatcher 130 may function as a primary controller of the integratedcircuit 100 that controls and manages access to a flow (movement) ofdata from memory to the one or more other storage and/or processingcircuits of the integrated circuit 100 (and vice versa). Additionally,the dispatcher 130 may schedule control execution operations of thevarious sub-controllers (e.g., periphery controllers, etc.) and theplurality of array cores 110.

In some embodiments, the processing circuitry of the dispatcher 130includes disparate circuitry including a compute instruction generatorcircuit 132 and a data movement instructions generator circuit 134(e.g., address generation unit or address computation unit) that mayindependently generate computation/execution instructions and datatransfers/movements schedules or instructions, respectively.Accordingly, this configuration enables the dispatcher 130 to performdata address calculation and generation of computation/executioninstructions in parallel. The dispatcher 130 may function to synthesizethe output from both the computer instructions generator circuit 132 andthe data movement instructions generator circuit 134 into a singleinstructions composition that combines the disparate outputs.

The single instructions composition generated by the instructionsgenerator 170 and/or the dispatcher 130 may be provided to the one ormore downstream components and integrated circuit array 105 and allowfor computation or processing instructions and data transfer/movementinstructions to be performed simultaneously by these various circuits orcomponents of the integrated circuit 100. With respect to the integratedcircuit array 105, the data movement component of the singleinstructions composition may be performed by one or more of peripherycontrollers 140, 150 and compute instructions by one or more of theplurality of array cores no. Accordingly, in such embodiment, theperiphery controllers 140, 150 may function to decode the data movementcomponent of the instructions and if involved, may perform operations toread from or write to the dual FIFOs 149, 159 and move that data fromthe dual FIFOs 149, 159 onto a data bus to the integrated circuit (orvice versa). It shall be understood that the read or write operationsperformed by periphery controllers 140, 150 may performed sequentiallyor simultaneously (i.e., writing to and reading from dual FIFOs at thesame time).

It shall be noted that while the compute instructions generator circuit132 and the data movement instructions generator circuit 134 arepreferably separate or independent circuits, in some embodiments thecompute instructions generator circuit 132 and the data movementinstructions generator circuit 134 may be implemented by a singlecircuit or a single module that functions to perform both computeinstructions generation and data movement instruction generation.

In operation, the dispatcher 130 may function to generate and schedulememory addresses to be loaded into one or more the periphery load store145 and the periphery load store 155. The periphery load stores 145, 155preferably include specialized execution units that function to executeall load and store instructions from the dispatcher 130 and maygenerally function to load or fetch data from memory or storing the databack to memory from the integrated array core. The first periphery loadstore 145 preferably communicably and operably interfaces with both thefirst plurality of dual FIFOs 149 and the first periphery memory 147.The first and the second periphery memory 147, 157 preferably compriseon-chip static random-access memory.

In configuration, the first periphery load store 145 may be arrangedbetween the first plurality of dual FIFOs 149 and the first peripherymemory 147 such that the first periphery load store 145 is positionedimmediately next to or behind the first plurality of dual FIFOs 149.Similarly, the second periphery load store 155 preferably communicablyand operably interfaces with both the second plurality of dual FIFOs 159and the second periphery memory 157. Accordingly, the second peripheryload store 155 may be arranged between the second plurality of dualFIFOs 159 and the second periphery memory 157 such that the secondperiphery load store 155 is positioned immediately next to or behind thesecond plurality of dual FIFOs 159.

In response to memory addressing instructions issued by the dispatcher130 to one or more of the first and the second periphery load stores145, 155, the first and the second periphery load stores 145, 155 mayfunction to execute the instructions to fetch data from one of the firstperiphery memory 147 and the second periphery memory 157 and move thefetched data into one or more of the first and second plurality of dualFIFOs 149, 159. Additionally, or alternatively, the dual FIFOs 149, 159may function to read data from a data bus and move the read data to oneor more of the respective dual FIFOs or read data from one or more ofthe dual FIFOs and move the read data to a data bus. Similarly, memoryaddressing instructions may cause one or more of the first and thesecond periphery load stores 145, 155 to move data collected from one ormore of the plurality of dual FIFOs 149, 159 into one of the first andsecond periphery memory 147, 157.

Each of the first plurality of dual FIFOs 149 and each of the secondplurality of dual FIFOs 159 preferably comprises at least two memoryelements (not shown). Preferably, the first plurality of dual FIFOs 149may be arranged along a first side of the integrated circuit array 105with each of the first plurality of dual FIFOs 149 being aligned with arow of the integrated circuit array 105. Similarly, the second pluralityof dual FIFOs 159 may be arranged along a second side of the integratedcircuit array 105 with each of the second plurality of dual FIFOs 159being aligned with a column of the integrated circuit array 105. Thisarrangement preferably enables each border 120 along the first side ofthe integrated circuit array 105 to communicably and operably interfacewith at least one of the first periphery controllers 145 and each border120 along the second side of the integrated circuit array 105 tocommunicably and operably interface with at least one of the secondperiphery controllers 155.

While it is illustrated in at least FIG. 1 that there are a first andsecond plurality of dual FIFOs, first and second periphery controllers,first and second periphery memories, and first and second load stores,it shall be noted that these structures may be arranged to surround anentire periphery of the integrated circuit array 105 such that, forinstance, these components are arranged along all (four) sides of theintegrated circuit array 105.

The dual FIFOs 149, 159 preferably function to react to specificinstructions for data from their respective side. That is, the dualFIFOs 149, 159 may be configured to identify data movement instructionsfrom the dispatcher 130 that is specific to either the first pluralityof dual FIFOs 149 along the first side or the second plurality of dualFIFOs along the second side of the integrated circuit array 105.

According to a first implementation, each of the dual FIFOs may usefirst of the two memory elements to push data into the integratedcircuit array 105 and second of the two memory elements to pull datafrom the integrated circuit array 105. Thus, each dual FIFO 149, 159 mayhave a first memory element dedicated for moving data inward into theintegrated circuit array 105 and a second memory element dedicated formoving data outward from the integrated circuit array 105.

According to a second implementation, the dual FIFOs may be operated ina stack (second) mode in which each respective dual FIFO functions toprovide data into the integrated circuit array 105 in a predeterminedsequence or order and collect the data from the integrated circuit array105 in the same predetermined sequence or order.

Additionally, the integrated circuit 100 preferably includes main memory160 comprising a single unified memory. The main memory 160 preferablyfunctions to store data originating from one or more sensors,system-derived or generated data, data from one or more integratedcircuit layers, data from one or more upstream devices or components,and the like. Preferably, the main memory 160 comprises on-chip staticrandom-access memory or the like.

Additionally, or alternatively, main memory 160 may include multiplelevels of on-die (on-chip) memory. In such embodiments, the main memory160 may include multiple memory (e.g., SRAM) elements that may be inelectrical communication with each other and function as a singleunified memory that is arranged on a same die as the integrated circuitarray 105.

Additionally, or alternatively, main memory 160 may include multiplelevels of off-die (off-chip) memory (not shown). In such embodiments,the main memory 160 may include multiple memory (e.g., DDR SRAM, highbandwidth memory (HBM), etc.) elements that may be in electricalcommunication with each other and function as a single unified memorythat is arranged on a separate die than the integrated circuit array.

It shall be noted that in some embodiments, the integrated circuit 100includes main memory 160 comprising memory arranged on-die and off-die.In such embodiments, the on-die and the off-die memory of the mainmemory 160 may function as a single unified memory accessible to theon-die components of the integrated circuit 100.

Each of the first periphery memory 147 and the second periphery memory157 may port into the main memory 160. Between the first peripherymemory 147 and the main memory 160 may be arranged a load store unitthat enables the first periphery memory 147 to fetch data from the mainmemory 160. Similarly, between the second periphery memory 157 and themain memory 160 may be arranged a second load store unit that enablesthe second periphery memory 157 to fetch data from the main memory 160.

It shall be noted that the data transfers along the memory hierarchy ofthe integrated circuit 100 occurring between dual FIFOs 149, 159 and theload stores 145, 155, between the load stores 145, 155 and the peripherymemory 147, 157, and the periphery memory 147, 157 and the main memory160 may preferably be implemented as prescheduled or predetermineddirect memory access (DMA) transfers that enable the memory elements andload stores to independently access and transfer data within the memoryhierarchy without direct invention of the dispatcher 130 or some mainprocessing circuit. Additionally, the data transfers within the memoryhierarchy of the integrated circuit 100 may be implemented as 2D DMAtransfers having two counts and two strides thereby allowing forefficient data access and data reshaping during transfers. In apreferred embodiment, the DMA data transfers may be triggered by astatus or operation of one or more of the plurality of array cores no.For instance, if an array core is completing or has completed aprocessing of first set of data, the completion or near-completion maytrigger the DMA transfers to enable additional data to enter theintegrated circuit array 105 for processing.

III. Method for Optimizing Loop Instructions in a Pipelined ProcessingStage

As shown by way of example in FIG. 2, a method 200 for optimizing nestedloop instructions includes identifying a candidate inner loop S210,implementing a loop optimization S220, executing a multi-part implicitbranch instruction S230, and executing a reserved bit S240.

The method 200 preferably functions to optimize loop instructions setsby implementing one or more techniques that simultaneously improvesperformance of an integrated circuit executing inner loop instructionswhile minimizing a code size of the inner loop instructions.

2.10 Candidate Loop Identification

S210, which includes identifying a candidate loop based on an evaluationof one or more target segments of nested loop instructions of aninstruction set with a reduced performance, may function to evaluate atarget instruction set to identify one or more instruction segmentshaving attributes that, during execution, reduce an operationalperformance of an integrated circuit. In a preferred embodiment, S210may function to perform the evaluation of a target instruction set atcompile time. That is, S210 may function to implement a compilerprogram, code optimization program, and/or the like that may function toperform a static evaluation of the target instruction set for targetcode segments with a reduced performance.

S210 may preferably function to evaluate one or more segments of thetarget instruction set that include nested loops. In one or moreembodiments, S210 may function to implement the compiler to find oridentify the most nested or most inner loop for each or any set of loopinstructions of the target instruction set. That is, S210 may functionto identify a most inner loop within a loop body as a target forevaluation. Accordingly, the most inner loop of a given loop bodypreferably relates to a (nest) loop instruction having the deepestdepth. In some embodiments, in which a counter may be implemented forenumerating a depth of given loop instruction whereby the most outerloop may be zero or one and for each depth within the most outer loop,the counter increments whereby the largest number of the countercorresponds to the most inner nested loop of a given loop body (i.e.,the most outer loop; counter=0 or 1). It shall be noted that adecrementing counter may additionally or alternatively be implemented inwhich the most outer loop corresponds to the highest count of a givencounter and the most inner loop of a loop body of the most outer loopcorresponds to a lowest count value (e.g., count=0 or 1).

In one or more embodiments, if an identified most inner loop of a loopbody includes one or more instructions within a body of the most innerloop for backwards branching, S210 may function to identify orautomatically select the most inner loop as a candidate or a target forloop optimization. The loop optimization, as described in more detailbelow, preferably reduces a penalty or a stall in an operationalperformance of an integrated circuit due to an increased number of clockcycles required for executing instructions for backwards branching orthe like.

Additionally, or alternatively, S210 may function to evaluate in or moreattributes of a target inner loop including, at least, a structure ofthe target inner loop to identify whether an instruction size or codesize of the target inner loop is at or below a instructions sizethreshold. In one or more embodiments, the instructions size thresholdpreferably relates to a maximum code size that a target inner loop mayhave for loop optimization. While it may be preferred that a code sizeof a target inner loop does not exceed the instruction size threshold,it shall be noted that loop optimization may be performed on any targetinner loop having any code size. It has been discovered that thetechnical benefit of the loop optimization described herein may havegreater efficacy in target inner loops having a tight or a small codesize (e.g., 1-3 lines of code or the like) relative to target innerloops have a code size that is not tight or small (e.g., a code sizeexceeding the instruction size threshold).

Additionally, or alternatively, S210 may function to identify a targetinner loop as a suitable candidate for loop optimization if the boundsof the loop are known or may be discoverable with ease (i.e., within areasonable amount of computing time below a discoverability threshold(e.g., a maximum time or period for discovery)). In such embodiments,the bounds of the loop (also referred herein as “loop bounds”)preferably relate to a combination of a starting condition and an endingcondition for a given (inner) loop. Accordingly, in one or moreembodiments, S210 may function to determine, identify, or confirm thatloop bounds for a target inner loop are known when a starting conditionand a termination condition for the target inner loop are known (i.e.,starting condition and/or terminating condition for the loop are statedwithin the loop body) or readily discoverable (e.g., via inspection ofan inspection of a structure of the code of the inner loop, the start orthe termination instruction may be derived). In one example in which mayinclude a loop variable, S210 may function to consider or determine thatthe loop bounds are known if a start or a termination condition of atarget inner loop may be derived using mathematics below a complexitythreshold (e.g., simple arithmetic: addition, subtraction, or the like).

2.20 Candidate Loop Optimization|Implicit Branch Instruction

S220, which includes implementing candidate loop optimization, mayfunction to optimize a candidate inner loop of an instruction set bymodifying the instruction set to include an implicit branch instructionfor at least controlling a looping operation of the candidate innerloop, as shown by way of example in FIG. 3. In a preferred embodiment,an implicit branch instruction as referred to herein preferably relatesto a multi-part branch instruction that is instructionally tethered to aloop body of an inner loop for controlling a looping back operation ofthe inner loop without the need for explicit backward branchinginstructions within the loop body of the inner loop. In one or moreembodiments, controlling the looping operations of the inner loop mayinclude starting and/or restarting an execution of a loop body of theinner loop for up to N−1 times and terminating an execution of the loopbody upon a satisfaction of a predetermined condition or a dynamiccondition.

Accordingly, at compile time, S220 may preferably function to implementa compiler to optimize the instruction set containing the candidateinner loop to simultaneously maintain an operational performance of anintegrated circuit executing the instruction set while minimizing a codesize of the instruction set. That is, the loop optimization, asdescribed in S220 may function to abstract from the loop body oreliminate a requirement for explicit backwards branching instructionwithin the loop body of a candidate inner loop. In this way, codeoptimizations, such as unrolling a code set for reducing operationalpenalties (e.g., stalls, wasted clock cycles, etc.) but correspondinglyenlarging the code set, may not be required thereby minimizing theinstruction set of a candidate inner loop and preserving memory used forstoring the instruction set.

2.22 Antecedent Instructions for Loop Body Control|Defining theMulti-Part Implicit Branch Instructions for Loop Optimization

In one or more embodiments, S220 includes S222, which includes settingand/or defining one or more parts of the multi-part implicit branchinstruction within the instruction set containing a loop body of acandidate inner loop. In such embodiments, the multi-part implicitbranch instructions (i.e., loop optimization) for optimizing thecandidate inner loop includes at least two parts, which may beimplemented as a modification of the instruction set by the compiler inany order, but for illustrative purposes a first part and a second partof the loop optimization are described.

In one or more embodiments, a first part of the loop optimization of acandidate inner loop may include augmenting the instruction set thatincludes the candidate inner loop with an antecedent instruction, whichmay sometimes be referred to herein as a “setup instruction”. S222 maypreferably add the first part of the loop optimization including theantecedent instructions in advance of and outside of the loop body ofthe candidate inner loop. That is, the antecedent instructions may becodified and/or arranged at a position within the target instruction setbefore the loop body instructions of the candidate inner loop. In thisway, the antecedent/setup instruction(s) may be executed or seen by aprocessing entity before the instructions defining the loop body of thecandidate inner loop.

In a preferred implementation, S222 may function to add the setupinstructions immediately prior to the instructions defining a loop bodyof the candidate inner loop. That is, in such embodiment, the setupinstructions may be added adjacent to an outside of or externally to theloop body of the candidate inner loop without intermediate instructionsbetween the setup instructions and the loop body of the candidate innerloop.

In a variant implementation, non-loop body instructions may be arrangedbetween setup instructions for a candidate inner loop and a loop body ofthe candidate inner loop. In such implementation, S222 may function toadditionally specify the target of the setup instructions whileaccounting for the non-loop body instructions.

Additionally, or alternatively, S222 may function to define the setupinstructions to include loop bounds (i.e., a start and end condition) ofa candidate inner loop. That is, S222 may function to construct theadditional setup instructions to include a start or an initiatingcondition that starts an execution of the loop body of the candidateinner loop together with a terminating or an ending condition that stopsan execution of the loop body of the candidate inner loop.

While it may be preferably that the terminating condition of a candidateinner loop be a known value, in some embodiments, S222 may function todynamically compute or dynamical derive a terminating condition for agiven candidate inner loop and include the derived terminating conditionas the terminal bound for stopping an execution of the loop body of thecandidate inner loop.

Preferably, S222 may function to store the loop bounds in one or moreregisters. In one embodiment, S222 may function to store a startcondition of a given loop bounds in a first register, as an immediate orthe like (i.e., a value known at compile time that is encoded into atarget instruction set) and a termination condition of the given loopbounds in a second register of second immediate. Additionally, oralternatively, S222 may function to define the setup instructions orantecedent instructions to include a branch target instruction or valueidentifying a relative location of the executable code for starting thecandidate inner loop.

2.24 Suffixation of Reserved Loop Back Bit

In one or more embodiments, a second part of the multi-part implicitbranch instructions for optimizing a candidate inner loop may include asuffixation of a single bit of instruction to a terminal instruction(i.e., last line instruction) of the loop body of the candidate innerloop an arrangement of the single bit of instruction within the loopbody of the candidate inner loop. In some embodiments, the single bit ofinstruction may be referred to herein as a “suffixation bit,” “reservedbit,” “tailing bit,” “sideband loopback bit” or simply a “loopback bit”.Accordingly, in a preferred embodiment, S220 includes S224, which mayfunction to identify a terminal or last instruction within a loop bodyof a candidate inner loop and affix a reserved bit to the terminalinstruction or within the loop body of the candidate inner loop thatcauses an integrated circuit executing the reserved bit to revert to orloop back to the branch target specified in the setup instructions, asdefined in S222. In one or more embodiments, the reserved bit may beadded along a same line of code as the terminal instruction of the loopbody of a candidate inner loop and distinctly affixed to the mostterminal character of the terminal instruction of the loop body.

Additionally, or alternatively, an execution of the reserved bit and aconsequent reversion to a branch target may function to increment ordecrement a counter associated with the iterations of the subject innerloop, as discussed in more detail below.

While, in one or more embodiments, a reserved bit may be added to a tailend of a terminal instruction of a loop body of a candidate inner loop,the reserved bit may not function to supplant, subjugate, or otherwise,modify an effective operation due to an execution of the terminalinstruction of the loop body having the reserved bit and mayadditionally, or alternatively, be added at any position or locationwithin the loop body of the candidate inner loop. Rather, in one or moreembodiments, the reserved bit may be added with a unique code structurerecognized by a distinct processing entity (e.g., dispatcher 130, IMD(i.e., dispatcher), or the like) for processing and/or executing thereserved bit distinctly from the terminal instruction. That is, a firstprocessing entity, such as a processing core (e.g., array core 110), mayfunction to execute an entirety of the loop body including the terminalinstruction while a second distinct processing entity (e.g., an IMD) mayfunction to execute instructions of the reserved bit independently ofthe terminal instruction.

In one or more embodiments, a structure of the reserved bit may includea unique or distinct instruction from a structure of the terminalinstruction in which a start of the reserved bit instruction may bedesignated with a special character, such as a dot or period. In suchembodiments, the special character of the reserved bit may be followedwith additional characters (e.g., “.lb” or the like) recognized by aprocessing entity as pointing to or reverting back to setup instructionsfor the loop body of the inner loop candidate. It shall be recognizedthat while any suitable special character may be used to designate orotherwise, indicate a start of the reserved bit instruction, in one ormore embodiments, S224 may not use a special character or the like fordesignating the reserved bit.

2.30 Execution of Multi-Part Implicit Branch Instruction

At runtime, S230, which includes executing a multi-part implicit branchinstruction for a given loop body, may function to identify and executeeach part of the multi-part implicit branch instruction for a loop bodyof an inner loop. In a preferred embodiment, S230 may first function toexecute the setup instructions component of the multi-part implicitbranch instruction to make ready the operational constraints for loopingback and terminating a looping back of a subject inner loop. Preferably,S230 may function to implement a distinct processing entity (e.g., anIMD) for executing the multi-part implicit branch instruction from atypical array processing core or from a processing entity that executesthe loop body of the inner loop.

2.32 Execution of the Setup Instruction(s)

In a preferred embodiment, executing the multi-part implicit branchinstruction may include first executing a setup instruction or anantecedent instruction for a given loop body of an inner loop. In thispreferred embodiment, S230 includes S232, may function to implement adistinct processing entity (e.g., a dispatcher, IMD, or the like) tostore each component of the loop bounds of the loop body of the innerloop. That is, S232 may function to configure or setup branch target andcopy and store each of the starting condition for the inner loop thatstarts an execution of the inner loop and the terminating condition thatterminates an execution of the inner loop in one or more of registersand immediates (i.e., the branch target), as shown by way of example inFIG. 4A. Preferably, in the copying and storing, S232 may function tocopy a location or otherwise notate the location of the firstinstruction of the loop body, per se, into a first distinct register orimmediate and further, copy a location or an address of the code for theterminating condition into a second distinct register or immediate.

Additionally, or alternatively, in executing the multi-part implicitbranch instruction, S232 may function to store a computed absolutetarget, i.e., program counter+relative target specified in the setupinstructions.

2.34 Dedicated Loop Counter Initialization & Tracking

Additionally, or alternatively, S230 includes S234, may function toimplement a dedicated loop counter that preferably tracks each iterationof a subject inner loop. In one or more embodiment, contemporaneous withan execution of setup instructions for a subject inner loop, S234 mayfunction to clear and initialize a loop counter to a starting value. Insuch embodiments, the setup instructions preferably includes a locationof one or more of the dedicated loop counter and a starting conditionfor the subject inner loop. In one or more embodiments, S234 mayfunction to initialize the loop counter to a value associated with thestarting condition (e.g., 0, 500, or the like). It shall be noted thatthe starting condition may be incremented or decremented and may be anysuitable value.

S234 may additionally, or alternatively, use a distinct processingentity (e.g., an IMD) for tracking a state of the loop counter througheach iteration of the subject inner loop. Thus, in parallel with anexecution of a loop body of subject inner loop by a processing entity(e.g., a processing array core), S234 may function to separately trackthe state of the loop counter, such that, in one or more embodiments,when the dedicated loop counter achieves or satisfies a terminationcondition (e.g., a loop counter value), an execution of the loop body ofthe subject inner loop may be terminated.

2.40 Sideband Loopback Bit Execution

S240, which includes executing the reserved bit, may function to executethe reserved bit of a loop body of a subject inner loop andcorrespondingly, terminate an execution of the inner loop or executeanother iteration of the subject inner loop. In particular, afterexecution of an iteration of a subject inner loop, S240, implemented bya distinct processing entity or the like, may function to read thereserved bit affixed to the most terminal instruction of a loop body ofthe subject inner loop, as shown by way of example in FIG. 4B. Asmentioned above, S240 may function to implement a distinct processingentity, such as an IMD, to read and execute the reserved bit.

In a preferred embodiment, executing the reserved bit may cause thedistinct processing entity to assess and/or change a value of a loopcounter that tracks the iterations of the subject inner loop togetherwith performing an evaluation of the termination condition against avalue of the loop counter for fully terminating any further iterations,looping, or executions of the loop body of the subject inner loop.

Accordingly, in one or more embodiments, S240 implementing the distinctprocessing entity may function to first increment or decrement the loopcounter to a new value. In some embodiments, the reserved bit mayfunction to point the distinct processing entity to the setupinstructions or setup branch target associated with the loop body of thesubject inner loop, which may direct the distinct processing entity to alocation or an address of the stored copy of the terminating conditionfor the subject inner loop and potentially, a storage location of astate of the dedicated loop counter for the subject inner loop. In onevariant implementation, an execution of the reserved bit by the distinctprocessing entity may function to point the distinct processing entitydirectly to the location or the address of the stored copy of theterminating condition. Once the new value of the loop counter isestablished by incrementing or decrementing the loop counter, S240 maycontemporaneously check or evaluate the new value of the loop counteragainst the terminating condition to determine whether the terminatingcondition is satisfied or not satisfied.

In the circumstance that S240 identifies that the terminating conditionof the subject inner loop is not satisfied, S240 may function to cause ajump or execute a branch to an address or a location of the firstinstruction or starting instruction of the loop body of the subjectinner loop and execute a new iteration of the subject inner loop.Alternatively, if S240 identifies that the terminating condition of thesubject inner loop is satisfied, S240 may function to cause atermination of an execution of the subject inner loop and, in someembodiments, proceed with processing another instruction other than theloop body of the subject inner loop.

It shall be noted that while the process flow and/or one or moreembodiments herein describe an optimization of inner loop instructions,as described in S210 and S220, being implemented together with anexecution of the multi-part implicit branch instructions, in one or moreembodiments, the optimization of the inner loop instructions and theexecution of the multi-part implicit branch instruction may beimplemented independently of each other. In particular, since it may becontemplated herein that the loop optimization may be performed atcompile time and the execution of the multi-part implicit branchinstruction may be performed at runtime, a distinct method forimplemented each technique is contemplated by the various embodimentsdescribed herein.

The systems and methods of the preferred embodiment and variationsthereof can be embodied and/or implemented at least in part as a machineconfigured to receive a computer-readable medium storingcomputer-readable instructions. The instructions are preferably executedby computer-executable components preferably integrated with the systemand one or more portions of the processor and/or the controller. Thecomputer-readable medium can be stored on any suitable computer-readablemedia such as RAMs, ROMs, flash memory, EEPROMs, optical devices (CD orDVD), hard drives, floppy drives, or any suitable device. Thecomputer-executable component is preferably a general or applicationspecific processor, but any suitable dedicated hardware orhardware/firmware combination device can alternatively or additionallyexecute the instructions.

Although omitted for conciseness, the preferred embodiments includeevery combination and permutation of the implementations of the systemsand methods described herein.

As a person skilled in the art will recognize from the previous detaileddescription and from the figures and claims, modifications and changescan be made to the preferred embodiments of the invention withoutdeparting from the scope of this invention defined in the followingclaims.

What is claimed:
 1. A method for improving a performance of anintegrated circuit, the method comprising: implementing one or morecomputing devices executing a compiler program that: (i) evaluates atarget instruction set; (ii) identifies one or more loop instructionswithin the target instruction set based on the evaluation; (iii)evaluates whether an inner loop body within the one or more loopinstructions comprises a candidate inner loop body requiring a loopoptimization that mitigates an operational penalty to an integratedcircuit based on one or more executional properties of the inner loopinstruction; and (iv) implements the loop optimization that modifies thetarget instruction set to include loop optimization instructions tocontrol an execution and a termination of the inner loop body therebymitigating the operational penalty.
 2. A system for improving aperformance of an integrated circuit, the system comprising: one or morecomputing devices executing a compiler program that: (i) evaluates atarget instruction set; (ii) identifies one or more loop instructionswithin the target instruction set based on the evaluation; (iii)evaluates whether an inner loop body within the one or more loopinstructions comprises a candidate inner loop body requiring a loopoptimization that mitigates an operational penalty to an integratedcircuit based on one or more executional properties of the inner loopinstruction; and (iv) implements the loop optimization that modifies thetarget instruction set to include loop optimization instructions tocontrol an execution and a termination of the inner loop body therebymitigating the operational penalty.